Ham Radio 2000 #2/Ham Radio 2000 - Volume 2.iso/HAMV2/PACKET/APRS805/README/TROUBLE.TXT

Text File | 1997-12-01 | 11KB | 201 lines

TROUBLESHOOTING GUIDE ver 75b

INSTALLATION:  Did you use PKUNZIP -d to get all the following subdirectories?
                   SYSTEM    (must have INITTAPR.TNC and RESTORE.TNC)
                   MAPS      (Must have at least WORLD or USA map)
                   BAKS
                   LOGS
                   HSTS
                   README
                   MAPLISTS (This is new in 75a and is REQUIRED)

CONFIGURATION:  Did you answer all menu prompts with SINGLE keys where
applicable?  This was the #1 problem found in Nov 97 for all prior
versions.  In otherwords, answering type of TNC with AEA instead of A
caused APRS to not see the "A".

COMMANDS:  All APRS commands are single keys.  The commands are usually
spelled out but only the first letter of each command word is needed.

OPERATION:  Is your receiver volume set high enough so that the DCD lamp
on the TNC lights whenever there is received data?

RECEPTION:  Verify reception by observing the DCD lamp whenever data is
heard.  If the data is strong enough, and ERROR-FREE, then it will be
displayed on the bottom line of the display.  Verify proper decoding by
observing the L and P lists for collection of packets from other stations.

TRANSMISSION:  Hit the XMIT-POS or XMIT-CQ command to force your system
to transmit.  Within a second or so, and after the channel is clear, your
transmitter should key up for about a second.

VERIFY COMMS BETEEN YOUR PC AND TNC:  Do an OPS-COMM-TNC to verify proper
serial interface to your TNC.  Hit ENTER and verify that you see the TNC
cmd: prompt.  If OK, then your serial PORT and TNC are communicating.  Hit
ESC to return to the program.  Do NOT type any commands to the cmd: prompt
because there are 100's of commands, each one of which can screw up the TNC!
APRS initializes your TNC using the commands in APRS\SYSTEM\IinitTAPR.TNC
or InitAEA.TNC.

VERIFY PROPER DATA FORMATS:  Using the OPS-COMM-TNC command, observe
received packets.  They should appear in approximately the following format:

   W3XYZ>APRS,WIDE:@123456/.......etc

The WIDE represents a list of digipeaters, but nothing else should be in the
received packet header other than the FROM call, APRS, digipeaters, and then
the COLON: that begins the data.  The data must be on the same line as the
header.  If not, set HEADERLINE OFF.  If any other stuff is being inserted
into the monitored packet, use your TNC manual to turn off all other monitoring
features.  If your TNC needs any special set up parameters, add them to the
InitTAPR or InitAEA.TNC files.


BAD COMMS BETWEEN PC AND TNC:  If there appears to be no data going to or from
the TNC and there is no cmd: prompt in the OPS-COMM-TNC mode, then stay in the
OPS-COMM-TNC mode and do a power cycle on the TNC power.  You should get a
RESET of the TNC and see several lines of initialization text.  If you do,
then ESC back to the program and do an alt-SETUP-TNC command to have the
program initialize the TNC parameters.  If there is still no data, then check
your serial port cables.  If You see characters but they are garbled, check
your TNC parity commands.

PARITY:  The MFJ and other standard TAPR TNC's need PARITY 0, but the
KAM needs PARITY 4.  We found a KPC-2 that needed PAR 3.  Keep trying!

AEA PRODUCTS:  Since some of the AEA setup commands are different than the
standard, you must tell APRS that you are using an AEA so that it will use
the commands in InitAEA.TNC.  Also, the AEA monitor format is different.
In some early models of the PK-12, the monitor function was not correct.
If you add the command BBSMSGS ON to the InitAEA.TNC file, then the PK-12
will emulate the standard TAPR monitoring function and work properly.

DISCONNECTED:  APRS periodically sends a D command to the TNC to be sure
that it is disconnected.  You will frequently see the TNC response saying
TNC is DISCONNECTED.  This is NORMAL!

TNC NOT RESPONDING:  Every time APRS sends a command to the TNC, it checks
to see if it got a cmd: response.  If not, it displays the warning "TNC
not responding".  If you see this warning ALL the TIME, then something is
wrong with the TNC mode or interface.  You will see this warning frequencly
whenever there is lots of data on the channel and APRS misses the cmd: in
the middle of all the traffic.  In this case, ignore the warning.

CAN'T VALIDATE:  If APRS cannot find the APRS\SYSTEM\VALID.sys file, then
it bombs out of the alt-S-SAVE routine without properly asking for
your validation number.

WRONG DIGIPATHS:  If you are using the /XX path specifier in your SEND
messages, then you must accept some missrouted packets.  This is because
the UNPROTO path is not assigned by the TNC until the instant the packet
is transmited.  Even though APRS wrote the correct PATH at the time it
set the packet to the TNC, if the channel is busy, then the packet may be
transmitted some time later and it will use whatever UNPROTO path is then
in the TNC at that instant.  To mitigate this problem somewhat, APRS will
add 5 seconds of dead time each time it changes the UNPROTO path.  There is
also a BIG problem with acks.  This is why this alternate path feature
should be used with caution.  See  NO ACKS.

NO ACKS:  Nothing you can do about it.  The other station's path must be
set to hit you, period.  If you are sending multiple messages in multiple
directions, then you have a problem if/when the other stations respond.
Your acks to their responses will ONLY got to your default DIGIPATH!  So
YOU must watch EACH incomming MESSAGE and decide if you need to change your
UNPROTO path to hit them.  For this reason, in general, only send alt-path
messages to un-attended or inactive stations.  Keep your main path set to
everyone with whom you are having a dialog.

HSP PROBLEMS:  Use the O-C-T mode to check out the HSP switch.  While
in O-C-T mode with your TNC, the F8 key will toggle the HSP switch
between the GPS and the TNC.  Also PacComm has written a file called
HSP-bugs.txt which is now included below.

CRASH ERROR CODES: The error codes are standard BASIC error codes.  Here
are the common ones for APRS:
   ERROR 5  - Illegal Function Call [Usually an incompatible video card]
   ERROR 6  - Math Overflow         [Some glitched packets..
   ERROR 7  - Out of Memory
   ERROR 14 - Out of String space   [Usually not enough conventional RAM]
   ERROR 61 - Disk Full             [Check your LOG and HSTS directories]
   ERROR 68 - Device not available  [Usually your COMM port is missing  ]
                                    [or WINDOWS stole it.  Boot to DOS...]
   ERROR 71 - Disk Not ready

OCCASSIONAL LOCKUPS:  It has been reported that older PC's with the old
16450 UART serial ports somehow occassionaly get locked up.  The newer
16550 UART serial ports have some built in buffering that seems to work
much better.  (BUT! see following comments...)

COMPAQ LAPTOP:  One person found that his NEW 486 laptop (AER) 4/33)
with the new 16550 UARTs would lock up.  He found that running the
setup program and setting COMFIFO 1 OFF solved his problems.

MORE 16550 LOCKUPS:  It is now generally known that there are lots of BAD
16550 chips out there.  If your system occasionally locks up when using the
HSP or ULTIMETER-2000, or just your TNC, then first, turn FIFO off in your
setups.  If that doesnt work, then run program contained in SMC.ZIP which
is purportedly a FIX for some of the bad 16550 problems.  YOu can find it
on @tapr.org in the /tapr/SIG/aprssig/upload directory.


HSP-bugs.txt 7.3a        APRS HSP Port Switch

     If You Have Difficulty Getting the APRS Port Switch to Work
There are two common problems to look for: The unit is not getting
power or the GPS signals are at too low a level.

Use a voltmeter to determine if there is DC Voltage coming in from
either the PC connector pin 6 or the TNC connector pin 6. If not,
check for another pin on the PC or TNC which can provide 6-12 VDC
and change the cable wiring accordingly.

If power is not available from the PC or TNC, then a 9 Volt battery
may be connected to supply power between Pin 6 (+) and Pin 5 (-) of
the RS-232 (PC) connector. This is also a good way to get the unit
operating initially after trouble is experienced.

    The other most likely cause of problems is inadequate drive in the
positive direction from the GPS receiver. In some cases, DTR is always
a little too high and this is the next most likely cause of trouble.
The circuit works only on positive going signals. The GPS data output
is fed through a 1k resistor and must have adequate drive capability
to get at least 0.7V on the base of transistor TR3 in order to turn
it on. This is normally the case, but SOME GPS receivers don't seem
to do this. Adding a 4k7 resistor between the data input and pin 6
of either the TNC or computer port of the adapter should provide enough
pull-up to make it work. The series 1k resistor on the GPS input cannot
be lowered in  value because TR4 is used to hard clamp the data and
would short circuit the GPS output.....

     DTR is used to switch the circuit between data sources. This needs
to go at least 1.2V POSITIVE when the circuit is in the TNC mode.
On some computers the low state was still too high and would cause
TR4 to remain turned on all the time, thereby preventing any GPS data
to be gathered. A simplistic fix to this was to add a second diode
in line with DD5 and thereby drop 0.7V. A better fix would be to vary
the value of RD9 up a little.

    Troubleshooting is performed by using APRS in HSP mode. Select Ops-
Comm-TNC to see TNC data (O-C-T).   Use the F8 key to toggle the HSP
switch.  The OPS-COMM-GPS command is for dual-port TNC's but will also
toggle the HSP switch to the GPS data.
over.

        Revision History for PacComm APRS Port Switch Units.

ECN 97 11/30/94: Add a 1N914 diode is series with D7 to work better
with GPS inputs that have minimal negative voltage swing.

ECN 103 3/13/95: Connect Pin 6 of the TNC connector to Pin 6 of the
PC connector to provide an additional source of supply voltage for
computers with no wiring to Pin 6. PacComm TNCs provide +5 VDC on
pin 6.

HECN 104 3/16/95: Change RD8 from 1k to 4.7k to improve TR2 switching
reliability.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Gwyn Reedy, W1BEL      [e-mail]        [e-mail]
[phone]        Fax:+[phone]     BBS: +[phone] (V.34)
PacComm Packet Radio Systems, Inc, 4413 N. Hesperides St, Tampa, FL 33614-7618